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Abstract 


This EIP adds many checks to EVM arithmetic and a new opcode to get the 
corresponding flags and clear them. The list of check includes underflows, overflows, 
division by zero. 


Motivation 


The importance of math checks in smart contract projects is very clear. It was an 
OpenZeppelin library and then incorporated in Solidity’s default behavior. Bringing 
this to EVM level can combine both gas efficiency and safety. 


Specification 
The key words “MUST", “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT", “SHOULD”, 
“SHOULD NOT", “RECOMMENDED”, “NOT RECOMMENDED", “MAY”, and “OPTIONAL” 
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in this document are to be interpreted as described in RFC 2119 and RFC 8174. 


Starting from BLOCK_TIMESAMP >= HARDFORK_TIMESTAMP 


Constants 
Constant Type Value 
INT_MIN int -(2**255) 
UINT_MAX uint 2 ** 256 


Flags 


Variable Type Initial Value 
carry bool false 
overflow bool false 


Two new flags are added to the EVM state: unsigned error ( carry ) and signed error 
( overflow ). The scope of those flags are the same as the program counter. Each 
frame of execution has their own flags. At the frame creation they are unset and they 
are updated in call. 


From this point forward a, b and c references the arguments in a math operation 
and res the output. c is only used if the operation takes 3 inputs. 


The carry flag MUST be set in the following circumstances: 


e When opcode is app ( @xe1) and res < a 

e When opcode is muL ( @xe2) and a !=@A res /a != b 

e When opcode is suB ( 9xe3) and b> a 

e When opcode is Div ( @xe4) or mop ( exe6 ); and b == ð 

e When opcode is Appmop ( exes ) and c == @ v ((a + b) / UINT_MAX > c) 
e When opcode is muLmop ( exes) and c == @ v ((a * b) / UINT_MAX > c) 
e When opcode is ExP ( exeA ) and ideal a ** b > UINT_MAX 

e When opcode is SHL ( @x1b) and res >> a != b 


The overflow flag is MUST set in the following circumstances: 


e When opcode is suB ( @xe3) and a != @ A sgn(a) != sgn(b) A sgn(b) == 


sgn(res) 
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e When opcode is App ( @xe1) and a != @ A sgn(a) == sgn(b) A sgn(a) != 
sgn(res) 

e When opcode is muL ( @xe2) and (a == -1 A b == INT_MIN) v (a == INT_MIN A 
== -1) v (a != @ A (res / a != b)) (this / represents spIv ) 

e When opcode is spiv ( exes) or smoD ( exe6 ); and b == ð v (a == INT_MIN A 
== -1) 

e When opcode is SHL ( @x1b) and res >> a != b (this >> represents SAR) 


The function sgn(num) returns the sign of the number, it can be negative, zero or 


positive. 
Value Mnemonic 6 a Description 
JUMPC @x5B 1 0 Conditionally alter the program counter. 
J_JUMPC = carry ? p s[ð] : p pc +1 
carry = overflow = false 
JUMPO @x5C 1 0 Conditionally alter the program counter. 
J_JUMPO = ovewrflow ? p s[ð] : p pc +1 
carry = overflow = false 
gas 


The gas cost for both instructions is G_high , the same as JuMPI . 


Rationale 


EVM uses two's complement for negative numbers. The opcodes listed above triggers 
one or two flags depending if they are used for signed and unsigned numbers. 


The conditions described for each opcode is made with implementation friendliness 
in mind. The only exception is EXP as it is hard to give a concise test as most of the 
others relied on the inverse operation and there is no native Loc . Most EXP 
implementations will internally use muL so the flag carry can be drawn from that 
instruction, not the overflow . 


The divisions by uInT_max used inthe aAppMoD and muLmop is another way to 
represent the higher 256 bits of the internal 512 number representation. 


Both flags are cleaned at the same time because the instructions are expected to be 
used when transitioning between codes where numbers are treated as signed or 
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unsigned. 


Backwards Compatibility 


This EIP introduces a new opcode and changes int EVM behavior. 


Test Cases 
TBD 


Reference Implementation 
TBD 


Security Considerations 

This is a new EVM behavior but each code will decide how to interact with it. 
Copyright 

Copyright and related rights waived via CCO. 
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